Most software applications are physically or logically split into separate components, which components need to intercommunicate via some communication protocol when the applications are executed. In order to achieve this intercommunication, each component needs to be able to identify other components, using some identity scheme. Such identity types are often application specific, and typically differ from the addressing scheme provided by the communication protocol which is used.
Assigning functional identities to software components is an important task, since designers typically want to build desirable properties into the assignment scheme. For example, a designer may typically prefer that the assignment scheme enable the number of software components to be extendable or shrinkable, without affecting the clients' (which are often just other components of the same application) ability to send messages to the components. Moreover, the designer may want to control the distribution of traffic towards the components, e.g., because some components are running on more powerful CPUs than others. Additionally, the designer may want to limit disturbances to the system during reconfiguration, e.g., state transfers between components, or usage of bandwidth and memory during advertisement of the identities.
A straightforward assignment scheme involves assigning a single identity to each software component 10, e.g., identity “0” to component A, identity “1” to component B, etc., as shown for example in FIG. 1(a). This assignment scheme is expandable, i.e., one could add a fifth component E (not shown in FIG. 1(a)) and provide component E with a new identity “4”. However, the loss or removal of a component, e.g., component C in FIG. 1(a), results in a period of unavailability until all clients 12 have been updated about the loss (e.g., as shown in FIG. 1(b)). A weakness of this assignment scheme is that it is tightly bound to the physical topology of the network, rather than responding to the needs of the applications. The client 10 typically determines the destination identity of a software component by using a hash function, and such hash functions are simpler, easier to maintain, and faster, if the target value range (Ri) is a fixed, uninterrupted sequence of identities, preferably with a size which is an exponential of 2, instead of a single identity. There may also be other, e.g., application specific, reasons for wanting to have a specific number of identities for each software component. However, identity assignment schemes which tie the identity range of a software component to the current number (N) of such components do not provide a satisfactory solution in most cases.
Another identity assignment scheme is illustrated in FIG. 2(a). Therein, the number of identities (i.e., 11) is much larger than the number of software components 20 (i.e., 4), but remains constant as the number of software components 20 changes. That is, instead of simply removing or adding identities as in the assignment scheme of FIGS. 1(a) and 1(b), the assignment scheme of FIGS. 2(a) and 2(b) distributes their representation according to the desired (i.e., equal or weighted) load balance among the software components. For example, as shown in FIG. 2(a), a client 22 may initially address each component 20 using a first set of identities. However, if a component C is removed, then the identities are redistributed as shown in FIG. 2(b). If a designer using the assignment scheme of FIGS. 2(a) and 2(b) wants to provide for exactly equal distribution before and after a component loss, the optimal identity range is Ri=N*(N−1)), with N being number of components. Adding a new, fifth, software component to the system illustrated in FIGS. 2(a) and 2(b) would thus imply moving some of the existing identities to the new component 20. However, since ((4*(4-1))=12) is not divisible by five, an equal distribution of identities would not result. A designer could instead choose to set the fixed number of identities as Ri=((N+1)*N*(N−1)) to obtain an equal distribution even at five components, but would then run into the same problem if the number of software components reached seven.
Thus it will be appreciated that the identity assignment schemes discussed above may suffer from, for examples issues associated with scalability and/or traffic continuity during a redistribution of identities. Accordingly, it would be desirable to provide systems, methods, devices and software for assignment of identities to software components which avoid the afore-described problems and drawbacks.